perm filename CLSUBS.MSG[COM,LSP]1 blob
sn#772839 filedate 1984-10-27 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 Introduction
C00005 ENDMK
C⊗;
Introduction
Welcome to the Common Lisp Subsets Subgroup.
In order to mail to this group, send to the address:
CL-Subsets@su-ai.arpa
Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:
CLSUBS.MSG[COM,LSP]
You can read this file or FTP it away without logging in to SAIL.
To communicate with the moderator, send to the address:
CL-Subsets-request@su-ai.arpa
Here is a list of the people who are currently on the mailing list:
Person Affiliation Net Address
Martin Griss HP griss.hplabs@csnet-relay (I hope)
Beau Sheil Xerox sheil@xerox
Dave Matthews HP matthews.hplabs@csnet-relay (I hope)
Bob Kessler Univ. of Utah kessler@utah-20
Jay Lark Teknowledge lark@sumex
Carl Hewitt MIT hewitt-subsets@mc
Govind Deshpande JPL deshpande@jpl-vlsi.arpa
Gary Brown DEC gbrown@dec-marlboro
Eric Benson Lucid eb@su-ai
Jerry Barber Gold Hill jerryb@mc
Jed Marti Rand marti@rand-unix
Chris Schmidt HPP schmidt@sumex
Alice Hartley BBN hartley@bbn
Gordon Novak Univ. of Texas novak@utexas-20
Guy Steele Tartan steele@tl-20a
Joe Ginder PERQ Joseph.Ginder@cmu-cs-spice
Jim Meehan Cognitive Sys. meehan@yale
The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.
Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete.
∂23-Sep-84 1624 RPG Introduction
To: cl-subsets@SU-AI.ARPA
Welcome to the Common Lisp Subsets Subgroup.
In order to mail to this group, send to the address:
CL-Subsets@su-ai.arpa
Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:
CLSUBS.MSG[COM,LSP]
You can read this file or FTP it away without logging in to SAIL.
To communicate with the moderator, send to the address:
CL-Subsets-request@su-ai.arpa
Here is a list of the people who are currently on the mailing list:
Person Affiliation Net Address
Martin Griss HP griss.hplabs@csnet-relay (I hope)
Beau Sheil Xerox sheil@xerox
Dave Matthews HP matthews.hplabs@csnet-relay (I hope)
Bob Kessler Univ. of Utah kessler@utah-20
Jay Lark Teknowledge lark@sumex
Carl Hewitt MIT hewitt-subsets@mc
Govind Deshpande JPL deshpande@jpl-vlsi.arpa
Gary Brown DEC gbrown@dec-marlboro
Eric Benson Lucid eb@su-ai
Jerry Barber Gold Hill jerryb@mc
Jed Marti Rand marti@rand-unix
Chris Schmidt HPP schmidt@sumex
Alice Hartley BBN hartley@bbn
Gordon Novak Univ. of Texas novak@utexas-20
Guy Steele Tartan steele@tl-20a
Joe Ginder PERQ Joseph.Ginder@cmu-cs-spice
Jim Meehan Cognitive Sys. meehan@yale
The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.
Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete.
∂27-Sep-84 0737 DUGGAN@UTAH-20.ARPA Please add me ty your group
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 27 Sep 84 07:37:16 PDT
Date: Thu 27 Sep 84 08:39:01-MDT
From: Jerry Duggan <duggan@UTAH-20.ARPA>
Subject: Please add me ty your group
To: cl-object-oriented-programming@SU-AI.ARPA, cl-subsets@SU-AI.ARPA
I work with Bob Kessler at the University of Utah.
Jerry Duggan
-------
∂02-Oct-84 1316 RPG Chairman
To: cl-subsets@SU-AI.ARPA
Now that we've basically got most everyone who is interested on the mailing
list, let's pick a chairman. I suggest that people volunteer for chairman.
The duties are to keep the discussion going, to gather proposals and review
them, and to otherwise administer the needs of the mailing list. I will
retain the duties of maintaining the list itself and the archives, but
otherwise the chairman will be running the show.
Any takers?
-rpg-
∂04-Oct-84 1435 GRISS%hp-hulk.csnet@csnet-relay.arpa Chairman
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 14:35:10 PDT
Received: from hplabs by csnet-relay.csnet id a011122; 4 Oct 84 17:26 EDT
Received: by HP-VENUS id AA16508; Wed, 3 Oct 84 06:38:31 pdt
Message-Id: <8410031338.AA16508@HP-VENUS>
Date: Wed 3 Oct 84 06:38:36-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Chairman
To: cl-subsets%su-ai.arpa@csnet-relay.arpa
Cc: GRISS@hplabs.CSNET
Source-Info: From (or Sender) name not authenticated.
I am willing to act as chairman/co-ordinator of the cl-subsets group.
I am currently exploring to what degree PSL (with appropriate
modifications) could be viewed as a CL subset. The version of PSL we
use at HP and some universities, has a significant CL compatibility
module (package system, pathnames, new reader, etc.). With some
changes, and the installation of this module in the basic system, a
useful and fast "PSL strength" subset could be evolved. We are writing
a simple translator to aid the transition from "old" PSL to "new" PSL.
I will first submit an initial proposal to the PSL and Standard LISP
communities for discussion, and then share the revised versions and
comments with the rest of our working group.
Are there any other subset proposals/partial compatibility packages or
translators (from subset to subset) being "brewed" out there?
Martin Griss
-------
∂13-Oct-84 1447 RPG Chairman
To: cl-subsets@SU-AI.ARPA
No one has been nominated as chairman of the Subsets subgroup. I will
need either a volunteer or a nomination. Please respond by October 24. At
the end of this month I want to see some ideas and proposals coming in on
this mailing list.
-rpg-
∂17-Oct-84 1138 jrg@cmu-cs-spice.arpa Re: Chairman
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 17 Oct 84 11:38:33 PDT
Date: Wednesday, 17 October 1984 11:53:23 EDT
From: Joseph.Ginder@cmu-cs-spice.arpa
To: Dick Gabriel <RPG@su-ai.arpa>
cc: cl-subsets@su-ai.arpa
Subject: Re: Chairman
Message-ID: <1984.10.17.15.52.41.Joseph.Ginder@cmu-cs-spice.arpa>
I thought Martin Griss volunteered for this. Did he not?
--Joe
∂17-Oct-84 1258 WHOLEY@CMU-CS-C.ARPA Chairman
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Oct 84 12:57:51 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Wed 17 Oct 84 15:52:39-EDT
Date: Wed, 17 Oct 1984 15:25 EDT
Message-ID: <WHOLEY.12056214685.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: cl-subsets@SU-AI.ARPA, Dick Gabriel <RPG@SU-AI.ARPA>
CC: Joseph.Ginder@CMU-CS-SPICE.ARPA
Subject: Chairman
In-reply-to: Msg of 17 Oct 1984 11:53-EDT from Joseph.Ginder at cmu-cs-spice.arpa
Joe's right. The following is in the archives...
-------------------------------------------------------------------------------
Date: Wed 3 Oct 84 06:38:36-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Chairman
To: cl-subsets%su-ai.arpa@csnet-relay.arpa
Cc: GRISS@hplabs.CSNET
Source-Info: From (or Sender) name not authenticated.
I am willing to act as chairman/co-ordinator of the cl-subsets group.
I am currently exploring to what degree PSL (with appropriate
modifications) could be viewed as a CL subset. The version of PSL we
use at HP and some universities, has a significant CL compatibility
module (package system, pathnames, new reader, etc.). With some
changes, and the installation of this module in the basic system, a
useful and fast "PSL strength" subset could be evolved. We are writing
a simple translator to aid the transition from "old" PSL to "new" PSL.
I will first submit an initial proposal to the PSL and Standard LISP
communities for discussion, and then share the revised versions and
comments with the rest of our working group.
Are there any other subset proposals/partial compatibility packages or
translators (from subset to subset) being "brewed" out there?
Martin Griss
-------------------------------------------------------------------------------
∂17-Oct-84 1437 marti@randgr Re: Chairman
Received: from RANDGR.ARPA by SU-AI.ARPA with TCP; 17 Oct 84 14:37:29 PDT
Received: by randgr.ARPA; Wed, 17 Oct 84 14:09:40 pdt
From: Jed Marti <marti@randgr>
Message-Id: <8410172109.AA13976@randgr.ARPA>
Date: 17 Oct 84 14:09:35 PDT (Wed)
To: cl-subsets@su-ai
Subject: Re: Chairman
Martin Griss has volunteered to act as chairman. If there needs to be a
formal nomination, then:
I nominate Martin Griss to the job of acting chairman of the Common Lisp
Subset Committee.
Jed Marti
∂23-Oct-84 0632 jrg@cmu-cs-spice.arpa Re: Import and Export
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 23 Oct 84 06:32:27 PDT
Date: Tuesday, 23 October 1984 09:25:42 EDT
From: Joseph.Ginder@cmu-cs-spice.arpa
To: cl-foreign-function-call@su-ai.arpa
cc: Tom Kaczmarek <KACZMAREK@usc-isif.arpa>, cl-subsets@su-ai.arpa
Subject: Re: Import and Export
Message-ID: <1984.10.23.12.56.30.Joseph.Ginder@cmu-cs-spice.arpa>
The CMU approach does allow other languages to make remote procedure calls
to Common Lisp. I don't see that the issue of a minimal kernel is
particularly relevant to this. For a foreign language to make calls on
Common Lisp does not require that the Lisp it is calling have some specific
functionality more than that it is there and can be called. I certainly
don't expect to define what functions are avaliable in fortran libraries in
order to define a foreign funcall mechanism for Common Lisp; I don't see how
anything different is implied by the reverse situation.
When we are concerned about supplying a minimal lisp for some application at
Perq (and CMU), we just load whatever application stuff there is into a lisp
and disembowel the lisp in such a way as to make all of the Common Lisp stuff
that isn't used available for GC. We then force a GC and save the new,
application-specific lisp core. The real problem then, becomes knowing what
minimal stuff the foreign language will call in order not to disembowel too
much. I don't really have much of a feel for how important such minimal
lisps are; I think this a task of the subset committee.
To the subset committee: I can imagine applications where the delivery
vehicle for a lisp application is a fairly limited piece of hardware; is a
subset appropriate or would the method described above be acceptable? We've
found that very straightforward methods of reducing a lisp core's size
result in dramatic space reductions; more thoughtful approaches should
result in really small lisps for delivery of applications without requiring
a specific minimal subset (although a "kernel" subset might be useful for
other reasons).
--Joe
∂23-Oct-84 1515 Faunt%hp-thor.csnet@csnet-relay.arpa removal form list
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 23 Oct 84 15:14:45 PDT
Received: from hplabs by csnet-relay.csnet id as05924; 23 Oct 84 17:56 EDT
Received: by HP-VENUS id AA29013; Tue, 23 Oct 84 13:33:08 pdt
Message-Id: <8410232033.AA29013@HP-VENUS>
Date: Tue 23 Oct 84 13:32:54-PDT
From: Doug <Faunt%hplabs.csnet@csnet-relay.arpa>
Subject: removal form list
To: cl-foreign-function-call%su-ai.arpa@csnet-relay.arpa,
cl-foreign-function-call-request%su-ai.arpa@csnet-relay.arpa,
cl-subsets%su-ai.arpa@csnet-relay.arpa,
cl-subsets-request%su-ai.arpa@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
Please remove dcm%hplabs@csnet-relay (or other equivalent address)
from your list, since this user doesn't exist here by that name,
and I'm tired of looking at the error messages.
-------
∂24-Oct-84 2036 WWHITE@SRI-KL.ARPA ad-hoc vs. planned subsets.
Received: from SRI-KL.ARPA by SU-AI.ARPA with TCP; 24 Oct 84 20:36:47 PDT
Date: Wed 24 Oct 84 20:36:45-PDT
From: Bill <WWHITE@SRI-KL.ARPA>
Subject: ad-hoc vs. planned subsets.
To: cl-subsets@SU-AI.ARPA
When we are concerned about supplying a minimal lisp for some application at
Perq (and CMU), we just load whatever application stuff there is into a lisp
and disembowel the lisp in such a way as to make all of the Common Lisp stuff
that isn't used available for GC. We then force a GC and save the new,
application-specific lisp core. The real problem then, becomes knowing what
minimal stuff the foreign language will call in order not to disembowel too
much. I don't really have much of a feel for how important such minimal
lisps are; I think this a task of the subset committee.
The problem I see with this approach is that it is ad-hoc for
each individual application. In all likelyhood, trying to combine
programs developed separately, will produce less and less savings
as the number of independent pieces goes up.
To the subset committee: I can imagine applications where the delivery
vehicle for a lisp application is a fairly limited piece of hardware; is a
subset appropriate or would the method described above be acceptable? We've
found that very straightforward methods of reducing a lisp core's size
result in dramatic space reductions; more thoughtful approaches should
result in really small lisps for delivery of applications without requiring
a specific minimal subset (although a "kernel" subset might be useful for
other reasons).
As I see it, the real reason for having well defined subsets is
to increase the ability to intgrate work from many places successfully.
Bill White
-------
∂25-Oct-84 1043 marti@randgr Re: ad-hoc vs. planned subsets.
Received: from RANDGR.ARPA by SU-AI.ARPA with TCP; 25 Oct 84 10:43:13 PDT
Received: by randgr.ARPA; Thu, 25 Oct 84 10:24:51 pdt
From: Jed Marti <marti@randgr>
Message-Id: <8410251724.AA11533@randgr.ARPA>
Date: 25 Oct 84 10:24:47 PDT (Thu)
To: cl-subsets@su-ai.ARPA
Cc: randgr!hearn@randgr
Subject: Re: ad-hoc vs. planned subsets.
In-Reply-To: Your message of Wed 24 Oct 84 20:36:45-PDT.
<8410250339.AA24984@rand-unix.ARPA>
Reasons for CL subsets:
Another reason for subsets is the efficiency issue. Many of our application
programs are incredibly slow, to the point where the programs are being
rewritten in other languages. We spent two frustrating man years
converting a large Interlisp program into C (still not complete), the sole
reason being speed. I cannot justify the view that once an application is
developed it should be converted into a static procedural language for
efficiency. It is too costly and fosters the conviction that it should have
been written in that medium in the first place.
I believe that a CL subset designed for speed is one that best serves
embedded applications:
1) a fast subset has fewer function calls to a smaller "library"
2) it has a better chance of being CONSless than a system with hidden
mechanisms
3) the human interface can be isolated and extracted when not needed
Jed Marti MARTI@RAND-UNIX
∂25-Oct-84 1534 WHOLEY@CMU-CS-C.ARPA ad-hoc vs. planned subsets.
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 25 Oct 84 15:34:34 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Thu 25 Oct 84 18:32:17-EDT
Date: Thu, 25 Oct 1984 18:32 EDT
Message-ID: <WHOLEY.12058345878.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Jed Marti <marti@RANDGR.ARPA>
Cc: cl-subsets@SU-AI.ARPA, randgr!hearn@RANDGR.ARPA
Subject: ad-hoc vs. planned subsets.
In-reply-to: Msg of 25 Oct 1984 13:24-EDT from Jed Marti <marti at randgr>
One of the properties of Lisp is that it is VERY easy to write VERY inefficient
programs by choosing inappropriate data structures. In older Lisps,
programmers were forced to use inappropriate data structures because things
like strings and vectors weren't around. In addition to the good old Lisp
objects like symbols and conses, Common Lisp provides the data structures that
any other modern programming language provides, and a few useful high-level
data structures (such as hash tables).
A Lisp programmer must choose his data structures well, as must any programmer.
I think it is the burden of the implementor to prevent the "primitives" from
incuring any non-obvious runtime penalties. I am an implementor, and I live
with that burden.
Given a good choice of data structures and algorithms, there is no real reason
why a Common Lisp program should run significantly slower than an equivalent
program written in a procedural language. A case in point: The Spice Lisp text
editor, Hemlock, is significantly faster (doing things like text modification
and redisplay) than Oil, a text editor written in Pascal running on the same
machine -- a machine designed to run Pascal! A lot of careful planning went
into Hemlock, and that planning payed off. Hemlock does much more than Oil,
and is easily extensible because it is written in Lisp.
A member of our user community here wrote a number of useful CAD tools in Perq
Pascal, and has since been turned-on to Common Lisp. He tells me that he can
develop programs many times quicker than he could in Pascal, and that the
performance lost by running them in Lisp instead of Pascal is less than 30%,
and sometimes 0%.
By limiting yourself to a subset with a "fast library" and few primitives, you
risk omitting a language feature that might be exactly right for some
application. I'm willing to bet that a good Common Lisp implementation will
provide that feature more efficiently than a subset with that feature kludged
on as an afterthought.
I can't help thinking that a good deal of the "incredible" slowness of the
application programs you mentioned is due partly to the Interlisp language,
which has been known to provide features at the expense of efficiency -- a fine
thing if you've got a Dorado in your office. Common Lisp claims heritage to
MacLisp, which put greater emphasis on efficiency.
I don't see how that fact that program X runs slowly in Lisp Y has anything to
do with making subsets of Lisp Z. There are a lot of free variables there.
--Skef
∂27-Oct-84 2155 RPG Hello folks
To: cl-subsets@SU-AI.ARPA
We now have a chairman of the subsets subgroup: Martin Griss
of HP. I think he will make an excellent chairman. For your
information I am including the current members of the mailing list.
I will now let Martin take over responsibility for the discussion.
Dave Matthews HP "hpfclp!subsets%hplabs"@csnet-relay
Stan Shebs Utah shebs@utah-20
John Foderaro Berkeley jkf@ucbmike.arpa
Jerry Duggan Univ of Utah duggan@utah-20
Rod Brooks MIT "brooks%oz"@mc
Skef Wholey CMU Wholey@cmuc
Martin Griss HP griss.hplabs@csnet-relay
Beau Sheil Xerox sheil@xerox
Bob Kessler Univ. of Utah kessler@utah-20
Bill White Teknowledge WWhite@sri-kl
Carl Hewitt MIT hewitt-subsets@mc
Govind Deshpande JPL deshpande@jpl-vlsi.arpa
Gary Brown DEC brown@dec-hudson
Eric Benson Lucid eb@su-ai
Jerry Barber Gold Hill jerryb@mc
Jed Marti Rand marti@rand-unix
Chris Schmidt HPP schmidt@sumex
Alice Hartley BBN hartley@bbn
Gordon Novak Univ. of Texas novak@utexas-20
Guy Steele Tartan steele@tl-20a
Joe Ginder PERQ Joseph.Ginder@cmu-cs-spice
Jim Meehan Cognitive Sys. meehan@yale
Jonl White Xerox jonl@xerox
Neal Feinberg Symbolics feinberg@scrc-stony-brook